There are many types of devices that need to be configured, controlled, and monitored remotely. For example, security, fire alarm, and access control systems have been offering at least some form of interface for remote configuration, control, and monitoring for the past several decades. In some of the early systems this was typically achieved using RS232 or RS485 links. Later, with the advent of local area networks and the Internet, these systems gradually started to take advantage of the “ubiquitous networking” revolution that was and still is unfolding around the world. Thus, dedicated RS232 and RS485 links gave way to direct communications over TCP/IP networks, while the proliferation of HTTP protocol has led to the emergence of a novice form of equipment control using the Internet browser.
Device configuration, control, and monitoring through the Web browser are effected by incorporating into the device necessary circuitry to connect this device to the TCP/IP network, implementing a TCP/IP protocol stack and Web server functionality within the firmware of the device, embedding into the device HTML pages necessary for configuration, control, and monitoring of the device, and providing a so-called common gateway interface (CGI) to allow the inclusion of dynamic data into the HTML pages output by the Web server of the device. This dynamic data may carry information about present device configuration, mode of operation, state, or any other useful information. The CGI interface can also be used to send to the device commands to change the configuration of the device or perform some other useful function.
Over-the-network configuration, control, and monitoring of such Web-enabled device may be achieved without installing any specialized software on the client machine. The user simply opens a standard Web browser, types in the address of the device and interacts with the device through the HTML pages “served” by the internal Web server of the device.
There are numerous variations on the above concept.
For example, U.S. Pat. No 6,446,192 (the “'192 Patent”) discloses a single integrated circuit chip that interfaces device control circuitry of a device to a client machine via a computer network. The chip implements complete internet protocol functionality. The chip also translates the information between network protocol formats and a format of the device.
According to the preferred embodiment of the invention disclosed in the '192 Patent, the chip sends to the client machine software comprising bytecode instructions (e.g. Java bytecode applet) executable by an interpreter running on the client machine (e.g. a Web browser with a Java Virtual Machine). Executing these instructions on the client machine creates a virtual interface to the device. Thus, the use of the HTML pages for accessing and altering the configuration of the device is complemented and augmented by the creation of the virtual interface.
Convenient as it may seem, device configuration through a Web browser has significant limitations. Namely, configuration, control, and monitoring of each such device incorporating its own Web server cannot be combined with configuration, control, and monitoring of another device, even if both devices are absolutely identical in nature. Working as a Web server, each device sends its own HTML pages, thus requiring the user to open a separate Web browser window for each device being accessed or, alternatively, access each device one-by-one. Certain systems may include hundreds, even thousands of devices and configuring them by accessing HTML pages separately on each device may become arduous and impractical.
One more disadvantage of the above method is that it requires uninterrupted connection to the device being configured, controlled, or monitored. Meeting this requirement when both the device and the client computer are connected to a small local-area network is trivial. Achieving the same for multiple devices distributed over the Internet is much more difficult.
Additionally, the reliability and availability of the data link to the device are typically adversely affected when the device is connected to the network through a wireless link (for example, a Wi-Fi connection) and the device itself is not stationary. This is the case for mobile terminals, portable data collecting equipment, hand-held computers and all other portable devices whose very nature dictates that these devices are constantly “on the move”. It is not practical to create a system for remote communications with such devices on the premise that uninterruptible connection to each device will be available at any time. In fact, in many instances a “window of opportunity” for accessing and configuring the device will be smaller than the time required to complete a desired transaction. That is, the breakdown of the established data link may occur before the configuration, control, or monitoring task is completed.
One more disadvantage of the above method is that accessing the device over the network from the client machine requires this device to have a static IP address. If the device is being accessed over the Internet, its IP address must also be “real” i.e. accessible from any point of the network. Such IP addresses are obtained from Internet Service Providers (ISPs), and consequently, there is a cost associated with obtaining and using them. Having multiple geographically distributed devices requires that each device is assigned its own static real IP address. Combined costs and management overhead associated with maintaining a real IP address and proper firewall setup for each device may be substantial.
Yet another disadvantage of the above method is that it creates significant management overhead due to the necessity of configuring a firewall on each device's site. In most installations, the device will be connected to the Internet through an ADSL link. This connection will usually be effected through an ADSL modem with built-in firewall function. The modem creates a firewall-protected private network and the device is connected to this network. Very often, the device will share this private network with personal computers and other devices.
A problem with the network configuration, as discussed above, is that while connecting from within the private network to a server outside does not require any setup on the firewall, connecting from outside of the private network to the device connected to the private network requires proper firewall setup, such as arranging “port forwarding” or “IP forwarding”. In a system that includes multiple devices on multiple firewall-protected private networks, the firewall setup creates a significant management overhead, not to mention the human factor: many IT departments view this kind of “opening” the network as potential vulnerability to external attacks and are not willing to compromise their networks in this way.
Finally, some kinds of connections to the Internet do not allow incoming connections in principle. For example, cellular networks, such as GPRS, will only allow the device to connect to the server on the Internet, and not the other way around.
For the above reasons, various large-scale systems consisting of a number of devices (nodes) rarely utilize the form of Web browser-based configuration, control, and monitoring described above. Rather, they typically rely on the intermediary system, such as a computer server running specialized software or purpose-designed hardware board, which acts as a central depository of data as well as the main coordinator of the system.
With this intermediary approach, the user is typically able to simultaneously control, configure, and monitor all or several devices in the system without having to perform repetitive operations on each device. For example, the system may be designed in such a way that giving a specific command to the central server will result in similar commands being sent by the server to each device (node) in the system. Conversely, events registered by individual devices are collected by the central server and stored in a single database thus offering the user a convenience of viewing all events in one place.
Such systems have a disadvantage of a very high cost of the design of specialized central server software or hardware board. Communications between the central server and the devices are usually based on a proprietary protocol designed specifically for each particular system. Typically, the central server software is inflexible and requires exact match between the devices and the central software for the system to work correctly. As a result, even a small change in the design of devices necessitates a corresponding change to the central server software. This results in high costs of maintaining the system.
Additionally, introducing different, previously unsupported devices into the system becomes a task akin to designing new central server software. For this reason, many systems of this class remain closed, non-expandable, and proprietary to this day.
Example: Vehicle Monitoring System
As an example, consider a vehicle monitoring system managing a fleet of cars, trucks, forklifts, or other vehicles. Each vehicle in the fleet is outfitted with a hardware device that collects a variety of data on the driver's behavior. This data includes driving speed, maximum acceleration and shocks experienced by the vehicle, driving patterns such as the amount of time spent driving vs. the amount of time spend idling. All this data is logged into the device's memory for later upload to the computer, typically through some form of a wireless interface. The device also works as an access controller for the vehicle—drivers use access codes or RFID cards to “log on” to the vehicle. This improves security and safety, the latter due to the ability of the system to disallow drivers not trained for a particular vehicle category. Driver's access to the vehicle can also be a subject to time limitations, such as “only within predefined shift”, “only within standard working time”, etc. Moreover, all vehicle log-ins and log-outs are recorded. In combination with vehicle driving patter records, this creates an extensive audit trail. The system can also perform a number of additional functions such as monitoring oil and gas level, battery charge, etc. In critical situations, the vehicle can be remotely immobilized by a command sent through the wireless interface. For example, airport facilities increasingly require remote deactivation capability for all ground vehicles as a form of gaining control over vehicles entering restricted areas such as runways.
Wireless connection to devices installed on the vehicles may be used to upload onto the device a list of parameters such as “maximum permitted driving speed” and “maximum permitted acceleration”; a well as a list of driver codes and permissions. The same wireless connection is used to download from the device an event log containing the history of log ins, log outs, as well as other events such as “engine started”, “engine shut off”, “excessive speed detected”, etc.
Vehicle monitoring systems suffer from a number of problems discussed above. Wireless connection to each vehicle is typically unstable. Even on a site that has blanket wireless coverage there are always situations and areas where the connection is unstable or unavailable. In a lot of cases, vehicles are also not confined to a particular site and only return to the base occasionally. This dramatically narrows the window of opportunity for communicating with any particular monitoring device.
An average fleet can include many different types of vehicles, and these different types may require different setup. Additionally, the vehicles are typically outfitted with the monitoring device at different times. As a result, some carry older monitoring devices, some carry newer ones, and the versions of monitoring device firmware may not be the same on all vehicles. In a regular working environment, it is next to impossible to collect all vehicles and update their devices and firmware simultaneously. Very often, some monitoring devices will receive an upgrade. For this upgrade to work, the PC software collecting the data from these vehicles will have to be upgraded too. This, in turn, will make it incompatible with older versions of monitoring devices still working on some vehicles. Experience shows that this cycle of update problems can be endless.